Azure AD を Verified Access 信頼プロバイダーに指定してみた

いわさ

2023.05.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

いわさです。

前回、Verified Access が GA になったのでまずはお手軽な IAM Identity Center で試してみました。

IAM Identity Center がお手軽ではあるのですが、組織ですでに導入済みの IdP を使いたいケースも多いと思います。
そこで今回は Verified Access のユーザー信頼プロバイダーで Azure AD を構成してみましたので設定方法などをご紹介します。

OIDC 全般同じような手順で出来るはずです。

公式ドキュメントは以下が参考になります。
それぞれの認証プロバイダー側の設定方法などを理解しておかないと AWS 側のドキュメントだけだと躓くかもしれません。

Verified Access 検証用のプライベートアプリをテンプレート化した

Verified Access は今後も検証することが多そうなので、プライベートネットワークのアプリケーション一式を CloudFormation でデプロイ出来るようにテンプレート化しておきました。
シングル AZ な本当にシンプルな構成のやつです。

このテンプレートでは上記の構成に加えてセキュリティグループがひとつ作成されます。
Internal ALB はそのセキュリティグループからのアクセスを許可するようになっているので Verified Access の ENI ではこのスタックで作成されるセキュリティグループを使ってもらうと良いと思います。

Azure AD 用の Verified Access 信頼プロバイダーを構築する

前述の内部アプリケーションと、Verified Access 信頼プロバイダー以外のコンポーネントについては本記事ではデプロイ手順について特に触れません。
内部アプリケーションについては CloudFormation の基本的な使い方を、Verified Access 信頼プロバイダー以外のコンポーネントについては前回の記事と同じ手順を想定しています。

まずは Verified Access 信頼プロバイダーで OIDC (OpenID Connect) を構成する際に必要な情報を確認してみましょう。

次の情報を Azure AD から取得する必要があります。

発行者
認証エンドポイント
トークンエンドポイント
ユーザーエンドポイント
クライアント ID
クライアントシークレット
範囲（スコープ）

上記は Azure AD で OIDC を使う際の基本的な要素なので簡単に構成出来そうですね。
Azure ポータルにアプリを登録し以下から確認出来ます。

アプリ登録

まずは Azure AD にアプリ登録をしないと始まりません。
Azure AD の App registrations メニューから New registration を選択します。

アカウントタイプは今回は検証用のテナントのシングルテナントを選択しました。
リダイレクト URI は後ほど設定します。

スコープ追加

AWS 公式ドキュメントにも次のように記述があり、openidスコープの追加が必要です。

13.Enter a space-delimited list of scopes defined with your identity provider. At minimum, the "openid" scope is required for Scope.

Azure AD アプリケーションではサイドメニューのAPI permissionsから権限の追加が可能です。

Verified Access 信頼プロバイダー構成時の「範囲」ではこのopenidを指定します。

シークレットを登録

クライアントシークレットを Verified Access 信頼プロバイダーに入力する必要があるので Azure AD アプリケーションの Certificates & secrets から新しいシークレットを登録します。
登録時だけ確認出来る Value を控えておいてください。これを Verified Access 信頼プロバイダー構成時のクライアントシークレットとして入力します。

その他の情報を取得

それ以外の情報は Azure AD アプリケーションの Overview あるいは OpenID Connect metadata document から確認出来ます。
クライアント ID は次のように Overview 画面のApplication (client) IDを取得します。

他の情報は上記のように Endpoints メニューから OpenID Connect metadata document が取得出来るのでそこから取得します。
以下のハイライト部分から取得します。

curl https://login.microsoftonline.com/11111111-2222-3333-4444-111122223333/v2.0/.well-known/openid-configuration | jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  1753  100  1753    0     0   4246      0 --:--:-- --:--:-- --:--:--  4275
{
  "token_endpoint": "https://login.microsoftonline.com/11111111-2222-3333-4444-111122223333/oauth2/v2.0/token",
  "token_endpoint_auth_methods_supported": [
    "client_secret_post",
    "private_key_jwt",
    "client_secret_basic"
  ],
  "jwks_uri": "https://login.microsoftonline.com/11111111-2222-3333-4444-111122223333/discovery/v2.0/keys",
  "response_modes_supported": [
    "query",
    "fragment",
    "form_post"
  ],
  "subject_types_supported": [
    "pairwise"
  ],
  "id_token_signing_alg_values_supported": [
    "RS256"
  ],
  "response_types_supported": [
    "code",
    "id_token",
    "code id_token",
    "id_token token"
  ],
  "scopes_supported": [
    "openid",
    "profile",
    "email",
    "offline_access"
  ],
  "issuer": "https://login.microsoftonline.com/11111111-2222-3333-4444-111122223333/v2.0",
  "request_uri_parameter_supported": false,
  "userinfo_endpoint": "https://graph.microsoft.com/oidc/userinfo",
  "authorization_endpoint": "https://login.microsoftonline.com/11111111-2222-3333-4444-111122223333/oauth2/v2.0/authorize",
  "device_authorization_endpoint": "https://login.microsoftonline.com/11111111-2222-3333-4444-111122223333/oauth2/v2.0/devicecode",
  "http_logout_supported": true,
  "frontchannel_logout_supported": true,
  "end_session_endpoint": "https://login.microsoftonline.com/11111111-2222-3333-4444-111122223333/oauth2/v2.0/logout",
  "claims_supported": [
    "sub",
    "iss",
    "cloud_instance_name",
    "cloud_instance_host_name",
    "cloud_graph_host_name",
    "msgraph_host",
    "aud",
    "exp",
    "iat",
    "auth_time",
    "acr",
    "nonce",
    "preferred_username",
    "name",
    "tid",
    "ver",
    "at_hash",
    "c_hash",
    "email"
  ],
  "kerberos_endpoint": "https://login.microsoftonline.com/11111111-2222-3333-4444-111122223333/kerberos",
  "tenant_region_scope": "AS",
  "cloud_instance_name": "microsoftonline.com",
  "cloud_graph_host_name": "graph.windows.net",
  "msgraph_host": "graph.microsoft.com",
  "rbac_url": "https://pas.windows.net"
}

ここまでの情報で Verified Access 信頼プロバイダーは次のようになります。

グループポリシーを設定

前回の記事で紹介したようにポリシーを使ってアクセスを拒否あるいは許可する条件を定義することが出来ます。
今回はポリシーにフォーカスしていないので以下のように対象テナントで認証出来たユーザーは全て許可する設定にしています。

permit(principal,action,resource)
when {
    true
};

リダイレクト URI を Azure AD アプリケーションに設定

この時点でアプリケーションドメイン（Verified Access エンドポイントのカスタムドメイン）へアクセスすると Azure AD への認証が要求されます。
しかし、次のようにサインインに失敗すると思います。

AWS 公式ドキュメント側に記述のとおりリダイレクト URI の構成が必要です。

Note
You will need to add a redirect URI to your OIDC provider's allowlist. You will want to use the ApplicationDomain of the Verified Access endpoint for this purpose. This can be found in the AWS Management Console, under the Details tab for your Verified Access endpoint or by using the AWS CLI to describe the endpoint. Add the following to your OIDC provider's allowlist: https://ApplicationDomain/oauth2/idpresponse

Azure AD の場合は次のメニューから設定することが出来ます。

今回は Verified Access エンドポイントへはhoge0501.tak1wa.comというカスタムドメインの CNAME レコードを登録しています。
そのため、リダイレクト URI は次のようになります。

アクセス出来た

`https://hoge0501.tak1wa.com/`へアクセスすると次のように Azure AD の認証が要求されます。
対象テナントはブランドのカスタマイズを行っているので表示メッセージや背景画像が以前カスタマイズしたものが表示されていますね。

サインインに成功すると、VPC 内の Web アプリケーションへ接続することが出来ました。

さいごに

本日は Azure AD を Verified Access 信頼プロバイダーに指定してみました。

思ってたより簡単に構成出来ました。Azure AD を使いたいという要望は多いと予想しています。この記事がどなたかの参考になれば幸いです。
また、OIDC のメタデータドキュメントの情報とクライアントとシークレットがあれば構成出来るので、どの IdP の場合でも似たような手順で構成出来るのではないでしょうか。